Компания VMware наконец-то обновила свой главный документ о производительности основной платформы виртуализации - "Performance Best Practices for VMware vSphere 6.7". Несколько ранее мы писали о документе "What’s New in Performance - VMware vSphere 6.7", в котором были рассмотрены основные нововведения последней версии продукта в плане производительности, но там было всего 13 страниц, а в этой книге о производительности - аж 88!

Само собой, книга покрывает аспекты не только новой функциональности vSphere 6.7, но и уже давно существующие фичи (с последними обновлениями, конечно). Вот о каких аспектах производительности платформы можно найти информацию в документе:

• Hardware-assisted virtualization
• Storage hardware considerations
• Network hardware considerations
• Memory page sharing
• Getting the best performance with iSCSI and NFS storage
• Getting the best performance from NVMe drives
• vSphere virtual machine encryption recommendations
• Running storage latency-sensitive workloads
• Network I/O Control (NetIOC)
• DirectPath I/O
• Running network latency-sensitive workloads
• Microsoft Virtualization-Based Security (VBS)
• CPU Hot Add
• 4KB native drives
• Selecting virtual network adapters
• The vSphere HTML5 Client
• vSphere web client configuration
• Pair-wise balancing in DRS-enabled clusters
• VMware vSphere update manager
• VMware vSAN performance

Штука эта, очевидно, обязательна к прочтению администраторам vSphere, которые хотят, чтобы у них в инфраструктуре все работало без сбоев и не тормозило.

Несколько интересных моментов из документа:

• Начиная с версии vSphere 6.7, платформа больше не поддерживает программную виртуализацию CPU (только аппаратную).
• vSphere Flash Read Cache (vFRC) может негативно влиять на производительность vMotion.
• Для VVols массив сам обнуляет блоки перед созданием тома, поэтому нет возможности указать тип диска "eager" или "lazy".
• Если вы используете виртуальный сетевой адаптер старой модели с пониженной пропускной способностью, например, Vlance, который показывает в гостевой ОС 10 Мбит/с - это не значит, что он будет работать на этой скорости. Он будет работать на скорости, максимально поддерживаемой физическим оборудованием и хостом ESXi.

Остальные полезные фишки - в документе.

На сайте проекта VMware Labs появилось очередное обновление vSphere Client 3.40 - клиента для управления виртуальной инфраструктурой через HTML5-интерфейс. Напомним, что прошлое обновление vSphere Client 3.39 вышло в середине июня этого года.

Давайте посмотрим, что нового появилось в vSphere Client 3.40:

• Функция проверки соответствия (Check compliance) для Host Profiles в кластере.
• Возможности Pre-check и remediate host (сделано не до конца) при накате профилей хостов.
• Функции Extract для профилей хостов и возможность для их изменения.
• Возможность управления избранным в Host profiles (на серверах vCenter 6.5).
• Функции копирования настроек между профилями хостов (для vCenter 6.5).
• Исправления ошибок.

Довольно-таки не густо для релиза, который готовили с середины июня. Загрузить VMware vSphere Client 3.40 можно по этой ссылке.

Компания StarWind Software, известная своим лидирующим на рынке решением Virtual SAN для создания отказоустойчивых хранилищ под виртуализацию, обновила свою продуктовую линейку. Теперь она заточена под создание гиперконвергентной инфраструктуры (управление различными аспектами - хранилищами, узлами, сетью - из единой точки) на базе вычислительных узлов, которые одновременно еще и являются узлами кластера хранилищ.

Недавно мы рассматривали некоторые аспекты резервного копирования на томах VVols в среде VMware vSphere. Одна из важных составляющих этого процесса - снапшоты (snapshots). Мы упоминали, что ввиду архитектуры VVols в плане снапшотов, снимки на уровне дисковых массивов на томах VVols работают быстрее при откате к снапшоту и консолидации (удалении всех снапшотов диска VMDK).

Сегодня мы попробуем разобраться, как это работает, и почему снапшоты в инфраструктуре VVols - это уже не так плохо, как раньше.

Снапшоты на томах VMFS

Сначала посмотрим на традиционную архитектуру снапшотов виртуальных машин на томах VMFS. Когда для машины делается снапшот, создается VMDK-файл, представляющий собой redo log (назовем его лог наката). В этот момент основной диск ВМ переводится в режим только для чтения (read only), а все новые операции записи (writes) идут в новый VMDK (дельта диск), который становится активным диском в плане новых операций чтения-записи для новых блоков, а старые блоки читаются из старого базового VMDK.

Если же мы хотим удалить один из снапшотов, мы должны склеить (накатить - redo) все сделанные операции записи новых блоков из логов наката к предыдущим точкам во времени. Например, если у вас есть базовая точка PIT1 (основной VMDK-диск), а также снапшоты PIT2 и PIT3, то чтобы удалить, например, снапшот PIT2 вам надо повторить (накатить) все операции его redo log на основном VMKD (PIT1), чтобы получить стабильную итоговую цепочку PIT1-PIT3 (без PIT2). Это довольно трудозатратная операция.

Если вы хотите откатиться к одному из снапшотов (revert), например, к исходному состоянию PIT1, то работает это очень просто - следующие снапшоты в цепочке просто отбрасываются (удаляются их VMDK):

Если же вы хотите удалить все снапшоты (консолидировать диск ВМ - операция consolidate), то процедура будет очень накладной. Об этой процедуре мы детально писали вот тут. Сначала PIT2 склеивается с PIT3, а потом уже получившийся диск склеивается с PIT1.

Таким образом, операция консолидации снапшота, который обязательно создается при резервном копировании, может занять длительное время.

Снапшоты для томов VVols

Давайте теперь посмотрим, как снапшоты работают в среде VVols. Здесь базовый диск находится в режиме чтения-записи всегда и всегда хранит в себе самое актуальное состояние. При создании снапшота диска VMDK происходит создание файла VMDK, который хранит в себе отличия (трекаются изменившиеся блоки), происходившие с какого-то момента времени (можно сказать, что это undo log). При этом основной контекст чтения-записи остается на основном VMDK.

В такой схеме операция revert будет происходит довольно долго по сравнению с таковой на VMFS - надо будет откатить изменения PIT3 в базовом диске, а потом изменения PIT2 (если мы идем к состоянию PIT1), но надо помнить, что откатываться к снапшоту приходиться не так уж и часто.

А вот операция консолидации (удаление всех снапшотов) - очень частая при резервном копировании. И вот тут для такой архитектуры работает это все моментально - мы просто откидываем ненужные объекты undo log, оставляя только базовый диск, который содержит в себе самое актуальное состояние на данный момент:

При необходимости вернуться к какому-то из снапшотов в среде VVols надо будет в базовом диске откатить все те изменения блоков (undo), которые зафиксированы в VMDK-диске снапшота, отслеживаемые с нужного момента времени (например, PIT1):

С каждым днем все больше компаний выбирают в качестве основы своей ИТ-инфраструктуры облако в модели IaaS.

Самый важный этап в проектах перехода на облачную модель организации инфраструктуры является планирование, и при выборе IaaS-провайдера необходимо учесть множество факторов, об одном из которых мы хотели бы поговорить сегодня. Речь пойдет о правильном тестировании системы хранения данных...

Таги: IT-Grad, IaaS, Storage, Performance, Cloud

Новые релизы различных продуктов VMware: апдейты vCenter, Horizon и vSphere Integrated Containers.

На днях компания VMware выпустила несколько минорных обновлений серверной продуктовой линейки. Давайте посмотрим, что нового стало доступно для загрузки:

1. Обновление VMware Horizon 7.5.1

В этом обновлении не появилось ничего нового, за исключением исправления безопасности CVE-2018-6971. Эта уязвимость заключается в том, что в процессе установки Horizon в файл vmmsi.log записывалась информация об учетных записях, которую могли считать привилегированные пользователи. Более подробно об этом рассказано тут.

Более подробно о самом обновлении можно прочитать в Release notes. Скачать VMware Horizon 7.5.1 можно по этой ссылке.

Здесь было сделано несколько улучшений служб управления:

• Pivotal tc Server заменен на сервер Tomcat версий 8.5.24 и 8.5.23.
• Кастомизация гостевых ОС Windows и Linux на vCenter Server поддерживает самые актуальные временные зоны.
• Поддержка TLS версии 1.2 для защищенного соединения с Microsoft SQL Server.
• Поддержка баз данных Microsoft SQL Server 2014 Service Pack 2, SQL Server 2016, SQL 2016 Service Pack 1 и SQL Server 2012 Service Pack 4.

Более подробно об обновлении можно прочитать в Release notes. Скачать VMware vCenter Server 6.0 Update 3g можно по этой ссылке.

3. Обновление VMware vSphere Integrated Containers 1.4.2

В этом обновлении только пофикшена проблема интеграции vSphere Integrated Containers Registry с компонентом сканирования на уязвимости Clair. Более подробно это улучшение описано вот тут.

Более подробно об обновлении можно прочитать в Release notes. Скачать vSphere Integrated Containers 1.4.2 можно по этой ссылке.

4. Обновление VMware vCenter Server 6.7.0c

Это обновление содержит в себе только исправления ошибок, которые описаны в разделе Resolved Issues документа Release notes. Скачать vCenter Server 6.7.0c можно по этой ссылке.

Мы много пишем о технологии Virtual Volumes (VVols) - например, тут, тут и тут. Она позволяет более гибко подходить к хранению объектов виртуальных машин за счет передачи некоторых функций работы с их данными на сторону хранилищ.

Несмотря на то, что структура хранения виртуальных машин на базе технологии VVols со стороны устройства хранения выглядит по-другому, нежели на классических томах VMFS, резервное копирование для таких ВМ традиционными средствами вполне поддерживается. Об этом мы уже рассказывали тут и вот тут, а сегодня немного дополним эти посты.

Для ПО резервного копирования тома виртуальные машины на томах VVols выглядят аналогично таковым на томах VMFS, поэтому ни схема, ни средства резервного копирования в инфраструктуре VVols не изменяются:

Резервное копирование делается через механизм vSphere APIs for Data Protection (VADP), который создает снапшот на хранилище, чтобы после его создания ПО для бэкапа могло забрать диски с данными ВМ. Отличие тут в том, что в этой схеме снапшот ВМ делает программное обеспечение дискового массива, на сторону которого передаются операции по работе со снапшотами и другие функции.

Кстати, интересная штука - стандартно для виртуальной машины в VMware vSphere можно сделать до 32 снапшотов, хотя VMware рекомендует делать их не более 2-3 в одной цепочке, так как большее количество может привести к различного рода проблемам. А вот с аппаратными снапшотами на томах VVols можно сделать 32 снапшота, и это никаких проблем не повлечет.

На массивах с поддержкой VVols есть поддержка операций "consolidate" и "revert" для снапшотов. В среде VVols они работают по-другому: там есть базовый VMDK, который всегда остается таковым, и куда идет запись, а также вместо записи изменений в redo log там есть read-only файлы снапшотов, которые не подцепляются в зависимую цепочку. При откате снапшота с базовым VMDK никаких длительных последовательных операций не производится (в отличие от VMFS), соответственно все это делать можно безопасно (подробнее - тут).

Также важно помнить, что использование Change Block Tracking (CBT) и vMotion для виртуальных машин на томах VVols может привести к порче данных (подробнее об этом тут). Эта проблема уже решена, но ее исправления будут доступны в следующих релизах vSphere 6.0, 6.5 и 6.7, а пока отключайте DRS для кластеров с виртуальными машинами на томах VVols.

На момент написания статьи VVols поддерживается для работы в трех режимах резервного копирования:

• Резервное копирование за счет монтирования виртуальных дисков (Hot Add backup) - в этом случае к одной ВМ монтируется диск VMDK другой ВМ и происходит его резервное копирование
• Резервное копирование по сети передачи данных (NBD backup) - это обычное резервное копирование ВМ по сети Ethernet, когда снимается снапшот ВМ (команды отдаются хостом ESXi), основной диск передается на бэкап таргет, а потом снапшот применяется к основному диску ("склеивается" с ним) и машина продолжает работать как раньше.
• Защищенное резервное копирование по Ethernet (NBDSSL) - то же самое, что и NBD backup, только с использованием SSL-шифрования при соединении через TCP/IP.

А вот метод без использования сети Ethernet (SAN-to-SAN backup) по-прежнему не поддерживается. Это происходит потому, что для в традиционной инфраструктуре VMFS есть виртуальный хост backup proxy, который говорит виртуальному модулю резервного копирования, какие блоки нужно читать по сети SAN. В среде VVols через VASA API компонент VASA provider на стороне физического сервера или дискового массива пока не может построить физический SAN-путь от хоста ESXi с томом VVols.

VASA provider нуждается в защите (если он реализован в виде виртуальной машины), так как он содержит в себе структуру томов VVols (и маппинги машин к устройствам), и если этот компонент будет потерян, то вы полностью потеряете управление над хранилищами (запущенные машины при этом еще будут работать).

Надо сказать, что вендоры решений с поддержкой VVols, как правило, сами реализуют отказо- и катастрофоустойчивость своих VP (а также их синхронизацию), но необходимо помнить, что это критически важный компонент, и неплохо бы делать его резервное копирование. Помните, что механизм vSphere HA в данном случае вам не помощник - он предназначен для других задач.

Собственно, практически все решения для резервного копирования виртуальных машин на платформе VMware vSphere на сегодняшний день поддерживают VVols:

Иногда бывает, что администратору платформы VMware vSphere требуется выгрузить список всех миграций vMotion виртуальных машин, которые произошли между хостами ESXi в последнее время, а также миграций Storage vMotion между хранилищами.

Для vMotion и SVMotion есть вот такой скрипт от Luc Dekens, который экспортирует миграции за указанное число часов или дней в файл XLS. Запустить его можно такой командой (скрипт точно работает для vSphere 6.5, как пишут здесь):

get-motionhistory -Entity (get-cluster "Cluster 1" | get-vm) -Days 2 | Export-csv -NoTypeInformation -UseCulture E:\VMware\Prod_vMotions.csv

На выходе будет вот такая табличка (обратите внимание, что миграции поделены на пользовательские и системные от DRS/SDRS, а также в поле Type указано, что это - vMotion или SVMotion):

Также ребята из компании Opvisor несколько адаптировали этот скрипт в разрезе миграций хранилищ Storage vMotion для подсчета общего объема миграций и выложили его тут. Работа этого скрипта дает вот такой результат:

Некоторые из вас (особенно администраторы VMware Horizon 7.5) знают, что в последней версии VMware vSphere 6.7 появилась возможность приостанавливать виртуальные машины, использующие vGPU, с высвобождением ресурсов графического адаптера под другие задачи. Ранее ресурсы графической карты возвращались платформе только при выключении виртуальной машины.

На эту тему VMware записала небольшое видео с демонстрацией данной возможности:

Для демо используются два 2 пула ресурсов: первый - под два виртуальных десктопа VMware Horizon, а второй - под две машины, использующие ресурсы vGPU для расчета моделей с помощью библиотеки машинного обучения TensorFlow.

Все 4 машины настраивают на использование политики, которая привязана к адаптеру NVIDIA Tesla P40 и позволяет использовать до половины ресурсов видеокарты. Сначала включают 2 виртуальных ПК Horizon, которые съедают всю карту, поэтому остальные две машины включить не удается. Но затем десктопы приостанавливают (Suspend), после чего машины с TensorFlow становится возможно запустить. Ну и в заключение тушат одну из машин TensorFlow, после чего успешно запускают один из виртуальных ПК Horizon (Resume).

Производитель графических адаптеров NVIDIA также записала небольшое демо своей технологии GRID для vSphere 6.7:

Здесь рассматривается несколько другой кейс. Десктоп с AutoCAD внутри ставят на паузу, после чего его обслуживают администраторы датацентра, не боясь того, что пользователь не сохранил свои данные в САПР. Затем после обслуживания десктоп запускают - и пользователь спокойно продолжает работу.

В общем, это нововведение весьма удобная и полезная штука.

Многие пользователи кластера отказоустойчивости хранилищ VMware vSAN замечали, что в настройках служб кластера есть такая опция "Erase disks before use", которая доступна при шифровании хранилища (vSAN Encryption).

Эта настройка позволяет очистить диск перед использованием шифрования на нем, чтобы соблюсти требования к безопасности хранения и обслуживания данных, например, NIST 800-88 Revision 1, определение "Clear":

Clear applies logical techniques to sanitize data in all user-addressable storage locations for protection against simple non-invasive data recovery techniques; typically applied through the standard Read and Write commands to the storage device, such as by rewriting with a new value or using a menu option to reset the device to the factory state (where rewriting is not supported).

В приложении A приведенного выше документа есть такая таблица (приведены только 2 строки из нее):

Чтобы соблюсти эти гайдлайны, кластер vSAN может вычищать предыдущие данные добавляемого диска перед первым использованием. Но при этом блоки заполняются не нулями или однотипными значениями - ведь это может вызвать сбой механизмов дедупликации и компрессии, поэтому в блоки записываются просто случайные данные.

Ставя галку "Erase disks before use" надо понимать, что процесс заполнения блоков случайными значениями занимает значительное время, которое зависит от типа используемого хранилища и инфраструктуры хранения в целом.

Также важно помнить, что включение vSAN Encryption влечет за собой шифрование только новых создаваемых дисковых объектов и не применяется к существующим на хранилище блокам (то есть их потенциально можно считать с диска, расшифровка их не потребуется). Таким образом, использование vSAN Encryption с настройкой "Erase disks before use" имеет смысл только при добавлении устройств, где ранее существовали данные.

Поэтому:

• Включайте опцию "Erase disks before use", когда:
  • Включаете vSAN Encryption для существующуего vSAN кластера, в котором требуется вычистить свободные блоки.
  • Добавляете хост, который имел ранее данные на локальных дисках, в кластер vSAN.
  • Выполняете операцию rekey для инициации процедуры deep rekey (запрос нового KEK и новых уникальных DEKs для каждого устройства vSAN).
• Не обязательно включать "Erase disks before use", когда:
  • Включаете vSAN Encryption для полностью нового кластера vSAN, в котором ранее не было данных на добавляемых дисках.
  • Добавляете в кластер vSAN хост, у которого на локальных дисках не было чувствительных данных.
  • Выполняете операцию rekey для инициации процедуры shallow rekey (только запрос нового KEK).

На сайте проекта VMware Labs появилась еще одна интересная штука - SaaS-решение vAssist. С помощью этого сервиса можно создавать и тренировать модели через интерфейс Natural Language Processing (NLP), которые могут обрабатывать пользовательские запросы на "человеческом" языке и предлагать различные действия для реакции на эти запросы (через API-вызовы или стандартные функции продукта). Это позволяет запрограммировать ботов, которые могут отвечать на различные запросы/обращения пользователей и администраторов, которые возникают в виртуальной инфраструктуре VMware vSphere. Например, с помощью этого сервиса был натренирован движок запросов к vRealize Automation.

С помощью vAssist пользователи могут спрашивать о доступности для них тех или иных сервисов и запрашивать их развертывание с помощью естественного языка. Также в сервисе доступен REST API для создания внешних интеграций с различными решениями.

Возможности vAssist:

• Движок NLU Engine для задания запросов и сущностей
• Настраиваемая воронка NLU pipeline
• Движок диалогов ML based Conversation Engine, который настраивается путем создания правил
• Приватность всех передаваемых данных
• Масштабируемый механизм со средствами устойчивости к сбоям
• Интерфейс REST API для интеграции с различными каналами и платформами

Воспользоваться сервисом vAssist можно по этой ссылке.

На днях компания VMware выпустила обновление решения VMware Lifecycle Manager 1.3, которое предназначено для для автоматизации установки, конфигурации, апгрейда/патчинга, управления изменениями, исправления конфигурации и мониторинга состояния компонентов vRealize Suite.

Давайте посмотрим, что нового появилось в этом продукте:

1. Поддержка vRealize Network Insight.

Она включает в себя:

• Поддержку версий 3.7 / 3.8
• Возможность указания размера инсталляции (Small, Medium или Large)
• Установку через мастер configuration wizard
• Экспорт существующих конфигураций окружения в формат JSON в целях воссоздания реплицированной копии окружения
• Отдельную лицензию для vRealize Network Insight

2. Улучшения управления контентом с поддержкой vSphere.

• Теперь доступно управление шаблонами виртуальных машин и спецификациями по кастомизации гостевых ОС (Customization specifications)
• Появилась интеграция с vSphere Content library (нужна версия vSphere 6.0+)
• Возможность ролевого доступа (RBAC) к тэгам контента (content tags)

3. Возможность пре-чека при апгрейде продукта.

• Запуск валидации на соответствие требованиям апгрейда
• Возможность просмотра ошибок, предпятствующих апгрейду, и выгрузка их в форме отчета

4. Прочие улучшения.

• Поддержка глобальной конфигурации NTP, а также на уровне отдельных серверов
• Группировка компонентов продуктов vRealize в мастере создания окружения
• Контент-пак для решения Log insight, что позволяет производить мониторинг инстанса Lifecycle Manager
• Поддержка новых версий vRealize Suite через саппорт-паки (support pack), что позволяет не обновлять целиком LCM при выходе новых версий vRealize Suite

Скачать VMware Lifecycle Manager 1.3 можно по этой ссылке. Документация доступна тут, а Release Notes - здесь.

Некоторые из вас знают, что у VMware есть лицензия VMware vCenter Server Foundation, которая позволяет подцепить к серверу vCenter до 4 хостов VMware ESXi. Такая лицензия стоит дешевле обычного vCenter и позволяет построить растянутый кластер (stretched cluster) из четырех хостов ESXi, например, на уровне основного датацентра и филиала (это обеспечивает отказоустойчивость HA на уровне каждой площадки):

Проблема здесь возникает тогда, когда вы пытаетесь добавить виртуальный модуль Witness Virtual Appliance на один из хостов. Так как Witness VM - это виртуальный хост ESXi, то несмотря на то, что он не исполняет виртуальных машин, сервер vCenter считает его пятым хостом и отказывается добавлять его.

Решение проблемы описано в Release Notes для VMware vCenter Server 6.5 Update 2 (см. пункт в самом низу) - нужно просто с самого начала импортировать Witness VM в inventory сервера vCenter (при добавлении первым он не будет съедать лицензию), после чего уже добавить 4 хоста ESXi, которые в этом случае подцепятся без проблем.

В графическом интерфейсе по управлению отказоустойчивым кластером VMware vSAN на платформе VMware vSphere отсутствует детальная информация о том, какая машина сколько физического пространства потребляет на уровне своих объектов (VMDK, vSWP и т.п.). Между тем, это может иногда оказаться полезным для администраторов, которые анализируют использование хранилищ и их рост.

Вильям Лам написал полезный PowerCLI-крипт, который позволяет такую статистику вывести - VSANVMDetailedUsage.ps1. Этот скрипт использует VSAN Management API, а в частности метод VsanQueryObjectIdentities() и свойство includeSpaceSummary.

Сценарий работает напрямую с хостом ESXi (поэтому надо предварительно установить переменные $ESXiHostUsername= "пользователь" и $ESXiHostPassword = "пароль"), а в качестве входного параметра для функции Get-VSANVMDetailedUsage надо указать имя кластера vSAN.

Соответственно, использовать скрипт нужно так:

Get-VSANVMDetailedUsage -Cluster "VSAN-Cluster"

В результате вы получите подробную информацию обо всех виртуальных машинах кластера, их дисковых объектах, сколько места они занимают на диске фактически, а также сколько под них зарезервировано:

Кроме того, скрипт можно использовать и для просмотра информации по дисковым объектам конкретной ВМ, например, так:

Get-VSANVMDetailedUsage -Cluster "VSAN-Cluster" -VM "Ubuntu-SourceVM"

Возможно, эта информация скоро появится в графическом интерфейсе следующих версий VMware vSAN.

Компания StarWind сегодня в 21-00 по московскому времени проводит интереснейший вебинар о своем виртуальном модуле на базе Linux для создания отказоустойчивых хранилищ под виртуализацию VMware vSphere - "Linux-based StarWind Virtual SAN – free and simple way to ensure high applications availability in vSphere environments".

Вебинар проведет Алекс Быковский, и вы сможете задавать вопросы на русском языке. Этот продукт очень давно ожидали пользователи StarWind (чтобы, например, не платить за лицензию Windows на сервер хранения), поэтому не пропустите уникальную возможность узнать подробности из первых рук.

Зарегистрироваться бесплатно!

По умолчанию тонкий клиент vSphere 6.7 Web Client показывает текущие задачи и алармы в виртуальной инфраструктуре от текущего пользователя, а чтобы увидеть эти события от других пользователей, надо сделать рефреш Web Client. Но, оказывается, есть возможность установить Live Refresh для веб-клиента таким образом, чтобы он обновлял сам последние задачи и алармы.

Делается это так:

1. Открываем на сервере vCenter файл со свойствами веб-клиента:

• Для vCenter for Windows - это C:\ProgramData\VMware\vCenterServer\cfg\vsphereclient\webclient.properties
• Для vCenter Server Appliance (vCSA) - это /etc/vmware/vsphere-client/webclient.properties

2. Добавляем в этот файл строчку конфигурации live.updates.enabled=true

3. Выходим из vSphere Web Client и логинимся по ссылке https://hostname:9443/vsphere-client/. Если вы залогинитесь по ссылке https://hostname/vsphere-client/, вы не увидите последние задачи и алармы других юзеров.

Эта возможность доступна, начиная с VMware vSphere 6.0 Update 1. Надо отметить, что для vCSA версии 6.5 и выше эта опция включена по умолчанию.

P.S. Кстати, в этом же файле вы можете добавить строчку tasks.refresh.rate = 60 для уменьшения частоты обновления панели задач (значение в секундах), либо можете выставить 10 (минимально) для частого обновления. Но часто обновлять задачи в окружениях с большим числом пользователей не рекомендуется, так как там могут возникнуть проблемы с производительностью веб-клиента.

Как вы знаете, компания VMware часто выпускает обновления для платформы VMware ESXi, которые закрывают проблемы безопасности и содержат исправления ошибок. Эти обновления можно загрузить вручную через портал My VMware или автоматически накатить через VMware Update Manager (VUM). Обновление содержит коллекцию VIB-пакетов, которые последовательно накатываются в среде ESXi. Эта коллекция VIB объединяется в бюллетень (bulletin), чтобы соблюсти порядок установки и зависимости, которые между ними заложены. Одно обновление содержит один или несколько бюллетеней.

Есть два типа бюллетеней для обновления VMware vSphere: патчи (patches) и роллапы (rollups). При любом выпуске обновления для ESXi есть как минимум бюллетень, который содержит основные системные пакеты - esx-base, vsan, and vsanhealth. Также в обновление могут быть включены и другие бюллетени, если есть необходимость в их обновлении.

Если обновление небольшое, то оно называется патчем (patch) и содержит небольшой набор пакетов, который закрывает дырки безопасности и некоторые баги. Время от времени VMware выпускает большой набор обновлений, который содержит не только исправления ошибок, но и некоторые новые возможности - оно называется rollup.

Раньше администраторам довольно трудно было убедиться, что у них накатаны все необходимые патчи в промежутке времени между большими мажорными релизами VMware vSphere. Теперь же, начиная с июня этого года, вместе с каждым патчем выходит еще и rollup update, который содержит в себе все обновления пакетов, которые произошли с момента последнего релиза VMware vSphere.

Вот так это выглядит в VMware Update Manager:

Все эти обновления описаны в соответствующей статье базы знаний VMware. Например, взгляните на VMware KB 55917 - там описаны все бюллетени обновления ESXi670-201806001 с соответствующими ссылками на их KB, а также указан rollup bulletin, который содержит все обновления VIB-пакетов с момента последнего релиза, в данном случае VMware ESXi 6.7:

Теперь можно просто накатывать этот роллап и не волноваться, что в вашей инфраструктуре что-то не обновлено.

Не так давно мы писали о том, что большинство вендоров решений для резервного копирования не сделали обновления своих продуктов для поддержки VMware vSphere 6.7. Сегодня компания Veeam восполнила этот пробел со своей стороны и выпустила апдейт Veeam Backup Replication 9.5 Update 3a, который полноценно поддерживает все возможности последней версии платформы виртуализации от VMware.

Давайте посмотрим на полный список новых возможностей этого обновления:

• Поддержка VMware vSphere 6.7.
• Предварительная поддержка VMware vSphere 6.5 Update 2 (будет выпущено еще одно обновление, когда VMware пофиксит баг).
• Поддержка VMware vCloud Director 9.1.
• Поддержка VMware Cloud on AWS версии 1.3.
• Поддержка гостевых ОС Microsoft Windows 10 April 2018 Update и Microsoft Windows Server 1803 в виртуальных машинах, а также систем Hyper-V на базе этой ОС. Также поддерживается и Microsoft System Center Virtual Machine Manager 1801.
• Улучшения производительности в режимах Direct Storage Access (DirectSAN) и Virtual Appliance (Hot Add).
• Сохранение Linux SUID и SGID при операциях "Copy To". Также появилась поддержка томов Btrfs размещенных на томе LVM.
• Задачи резервного копирования Storage snapshot-only для vCloud Director работают для всех поддерживаемых хранилищ (ранее было доступно только для NetApp).
• Улучшения и исправления ошибок для служб Veeam Cloud Connect (подробнее - тут).
• Исправления ошибок.

Полный список всех нововведений Veeam Backup Replication 9.5 Update 3a приведен в Release Notes. Скачать его можно по этой ссылке. Инструкции по обновлению приведены тут.

Компания VMware сделала доступным список часто задаваемых вопросов по обновлению до последних версий платформ виртуализации - VMware vSphere Upgrade FAQ. В данных вопросах рассматривается как процесс обновления, так и дальнейшее функционирование инфраструктуры VMware vSphere 6.5 и 6.7.

Список вопросов по апгрейду на vSphere 6.7 и 6.5 затрагивает следующие темы:

• Deployment Topologies
• Migration
• General Upgrade
• Management Clients
• Licensing
• Interoperable Solutions
• Networking
• Storage
• vCenter Server Appliance (VCSA)

Тем, кто планирует обновление, конечно же, рекомендуется эту страничку почитать. Кстати, помните, что апгрейд с недавно вышедшей версии VMware vSphere 6.5 Update 2 на VMware vSphere 6.7 пока еще не поддерживается.

В конце мая компания VMware выпустила обновленную версию продукта VMware Unified Access Gateway (UAG) версии 3.3. Это решение представляет собой шлюз для доступа к инфраструктуре VMware Workspace ONE и VMware Horizon. Шлюз используется для безопасного доступа внешних авторизованных пользователей ко внутренним ресурсам решения Workspace ONE, виртуальным десктопам и приложениям.

Давайте посмотрим, что нового появилось в этом продукте:

1. Поддержка механизма Device Certificate Authentication для обратного прокси-сервера.

Аутентификация на базе сертификатов вместе с поддержкой Web Reverse Proxy используется для защиты внутренних сайтов, таких как SharePoint, Outlook OWA и т.п. при доступе с внешних устройств.   

2. Логирование действий администратора.

Теперь все действия пользователя admin записываются в файл audit.log:

Также записываются и операции по скачиванию данного лога.

3. Отсутствие зависимости от Network Protocol Profile.

Раньше на платформе vSphere профиль Network Protocol Profile (NPP) или IP Pool должны были иметь соответствующие сети на стороне UAG с такими же настройками IP, шлюза и т.п. Теперь нет необходимости настраивать все это на стороне vSphere, а вместо этого при развертывании UAG нужно указать маску IPv4, префикс IPv6 и шлюз по умолчанию.

4. Поддержка TLS Port 443 Sharing.

Теперь такие сервисы, как Horizon Blast, туннель для конкретного приложения, Content Gateway и Web reverse proxy идут по одному порту 443. Это минимизирует требования к добавлению новых правил в сетевой экран в DMZ.

Этот механизм также можно отключить через настройку tlsPortSharingEnabled.

5. Одновременная работа с IPv4 и IPv6 (Dual Mode).

С помощью Dual Mode пользователи инфраструктуры VMware Horizon могут использовать смешанный парк устройств, работающих, как с IPv4, так и с IPv6 в рамках одного соединения (например, карточка IPv6 на мобильном устройстве и NIC с IPv4 на Connection Server).

6. Редактирование настроек сетевого адаптера через веб-интерфейс.

В веб-интерфейсе виртуального модуля UAG администратор теперь может задавать IP-настройки сетевого адаптера:

7. Новая операционная система виртуального модуля.

Теперь Virtual Appliance решения UAG работает на базе собственной операционной системы VMware - Photon OS. которая позиционируется как наиболее защищенная система для виртуальной инфраструктуры.

8. Настройки масштаба инфраструктуры.

Теперь при развертывании UAG можно задать одну из двух настроек масштаба:

• Standard – рекомендуется при развертывании Horizon до 2000 одновременных подключений, либо для инфраструктуры Workspace ONE UEM (мобильные устройства) до 10 000 подключений.
• Large – это нужно для инфраструктуры Workspace ONE UEM, когда нужно поддерживать более 10 000 одновременных подключений. Это позволяет механизмам Content Gateway, Per App Tunnel & Proxy и Reverse Proxy использовать один виртуальный модуль UAG.

Скачать VMware Unified Access Gateway 3.3 можно по этой ссылке.

Недавно мы писали о новой утилите на сайте проекта VMware Labs - ESXi Compatibility Checker, которая представляет собой Python-скрипт, проверяющий аппаратные компоненты хост-серверов на совместимость с платформой VMware vSphere и ее различными версиями. На днях вышла обновленная версия этого сценария, которая имеет несколько важных нововведений.

1. Офлайн режим работы.

Теперь можно собрать данные об аппаратных конфигурациях в формате JSON на системе без доступа к интернету, а потом проверить собранные конфигурации на другой системе с онлайн-доступом на предмет соответствия требованиям HCL (Hardware Compatibility List).

Для сбора конфигурации нужно использовать такую команду:

$compchecker.py -s <host> -u <user> -g <json-data-filename>

А для проверки на аппаратные требования такую:

$compchecker.py -f <json-data-filename>

2. Поддержка нескольких серверов vCenter.

Теперь оператор -s поддерживает несколько имен хостов через запятую. Таким образом, вы получите один отчет о совместимости для нескольких управляющих серверов vCenter. Делается это следующей командой:

$compchecker.py -s <host1>,<host2>,<host3> -u <user>(,<user>)

3. Новая информация в отчете.

Теперь в отчете есть такая информация об окружении, как "Installed Release", "Checked Release", а также информация об аппаратном обеспечении.

4. Задание прокси-сервера для работы скрипта.

С помощью параметра -p можно задать адрес прокси-сервера, через который будет происходить коммуникация при проверке аппаратных конфигураций.

Скачать скрипт ESXi Compatibility Checker можно по этой ссылке.

Не так давно мы писали о том, что вышло обновление клиента VMware ESXi Embedded Host Client, позволяющего управлять хост-сервером ESXi через удобный веб-интерфейс. Сегодня мы поговорим о настройке клиента NTP на хосте, который необходим, чтобы виртуальные машины синхронизировали свое время с хостом через VMware Tools. Тулзы синхронизируют свое время при старте машин, операциях по созданию снапшотов (а значит и при создании бэкапов), vMotion и некоторых других событиях.

Если на хосте установлено неправильное время, то это может привести к проблемам при логине, а также невозможности старта службы vpxd на сервере vCenter Server Appliance (vCSA).

Давайте запустим ESXi Host Client по ссылке:

https://<esxi_ip_or_hostname>/UI

Далее нужно пойти в Manage > System > Time and Date, где нажать Edit settings:

Появится диалог настройки синхронизации времени хоста средствами службы NTP (ESXi NTP Client).

В поле NTP Servers нужно указать адрес сервера времени, а в поле NTP service startup policy есть 3 варианта:

• Start and stop with port usage - если выставлена эта опция, то службы NTP будут запускаться автоматически при доступности порта NTP (UDP Port 123) и отключаться, если он недоступен (например, применен Security Profile для сетевого экрана, который выключает доступ по этому порту). VMware рекомендует использовать эту настройку по умолчанию.
• Start and stop with host - включает и отключает службы NTP при загрузке хоста ESXi или перед его выключением.
• Start and stop manually - ручное управление службами NTP с точки зрения старта и остановки.

После того, как вы настроили политику NTP-клиента, он сам еще не запустится - его нужно запустить вручную из меню Actions:

Если же вы используете для настройки времени на хосте ESXi клиент vSphere Web Client, то они находятся в разделе Configure > System > Time configuration для выбранного хоста ESXi:

Недавно мы писали о том, что вышла очередная версия клиента VMware vSphere Client 3.39 на базе технологии HTML5, а сегодня скажем пару слов о том, как можно его обновить в вашей виртуальной инфраструктуре, где установлен этот виртуальный модуль.

Самый простой способ обновления vSphere Client - сделать это через интерфейс FAMI UI. Для этого нужно пойти по ссылке:

https://<ip-address-of-client>:5490

И после логина в консоль управления модулем (по умолчанию логин и пароль - root/demova) нажать в правом верхнем углу кнопку UPDATE VSPHERE CLIENT (скриншот ниже - старый, для версии 3.27):

Если же по какой-то причине обновить так не получается (например, вам нужно использовать прокси-сервер), то можно просто зайти в консоль vSphere Client и обновить его с помощью wget. Делается это следующей последовательностью команд (пример указан для версии 3.39):

wget https://download3.vmware.com/software/vmw-tools/vsphere_html_client/installer-3.39.0.bsx

chmod +x installer-3.39.0.bsx

/etc/init.d/vsphere-client stop

./installer-3.39.0.bsx

/etc/init.d/vsphere-client start

Также можно использовать следующие параметры wget:

• -no-check-certificate - если появляются какие-то ошибки с некорректными сертификатами.
• --execute https_proxy=: - задает адрес прокси-сервера, через который надо производить скачивание (после двоеточия указывайте адрес прокси).

Также еще рекомендуем два полезных документа о vSphere Client - H5 Client Deployment Instructions and Helpful Hints и Create a new certificate for HTML5 client fling.

Далеко не все пользователи продуктов VMware и платформы vSphere в частности знают, что есть такое средство, как VMware Skyline. Это проактивная технология VMware для предоставления расширенной технической поддержки некоторым клиентам для продуктов VMware vSphere (включая vSAN 6.6 и более поздние версии) и VMware NSX (поддержка других продуктов ожидается).

С помощью технологии VMware Skyline пользователи и инженеры технической поддержки VMware (Technical Support Engineers, TSEs) могут просматривать некоторые заключения о работе виртуальной инфраструктуры и основные рекомендации по ее улучшению, которые содержатся в специальном отчете Skyline Operational Summary Report (OSR).

Также инженеры техподдержки VMware в рамках решения проблем заказчиков могут видеть весь их Inventory, а также все их обращения в техническую поддержку (Support Requests, SRs). Все это позволяет службам Global Support Services (GSS) быстро и эффективно решать проблемы заказчиков, а что более важно - предотвращать их.

По результатам анализа данных составляется сводный отчет (OSR), предоставляющий информацию о проблемах различной степени критичности:

Найденные проблемы можно отсортировать по степени критичности в веб-интерфейсе Skyline, а также отфильтровать по различным компонентам:

А вот так выглядят для вас и инженера TSE найденные проблемы в вашей инфраструктуре и возможные рекомендации по их устранению, которые вы можете с ним обсудить (обратите внимание, что для некоторых проблем даются ссылки на патчи ESXi их устраняющие):

В видео ниже можно посмотреть, как выглядит Skyline Operational Summary Report (OSR), получаемый в ходе работы :

Службы VMware Skyline доступны бесплатно пользователям Premier Services, а также тем, кто пользуется расширенным уровнем технической поддержки (Production Support). При этом в рамках Premier Services вам будут доступны рекомендации системных инженеров, их советы и дискуссии с ними, а в рамках Production Support все операции будут происходить через портал самообслуживания.

Для работы сервисов Skyline в вашей виртуальной инфраструктуре потребуется развернуть виртуальный модуль VMware Skyline Collector, который привязан к vCenter Server и/или NSX Manager. Он будет в автоматическом режиме собирать все необходимые данные в инфраструктуре VMware vSphere (а именно - конфигурации, доступные возможности и данные о производительности систем). Он также собирает информацию о происходящих изменениях и событиях, распознает паттерны определенных проблем, а также анализирует информацию с помощью как жестких правил, так и гибких механизмов машинного обучения (machine learning).

На настройку виртуального модуля Skyline Collector потребуется около получаса, после чего он будет работать в полностью автоматическом режиме.

Надо отметить, что данные о виртуальной инфраструктуре будут передаваться в VMware, но они будут идти по надежно защищенному каналу и храниться в собственном защищенном хранилище VMware на территории США (VMware Analytics Cloud, VAC). Если у вас несколько площадок, то данные, собираемые с каждой из них, будут агрегироваться и храниться централизованно. Помните, что сервис Skyline хранит такую чувствительную информацию, как имена хостов и IP-адреса.

Надо отметить, что для продукта vSAN часть сервиса Skyline доступна обычным пользователям. Это решение vSAN Support Insight, которое позволяет всем пользователям, участвующим в программе CEIP (Customer Experience Improvement Program), получить доступ к расширенной аналитике vSAN (даже без подключенного сервиса Skyline):

Так выглядит консоль vSAN Support Insight:

Если у вас появился интерес к сервису VMware Skyline, и у вас есть активный контракт Premier Services или Production Support, вы можете узнать больше и подписаться на него по этой ссылке - Managed Access Program.

Также у VMware Skyline есть своя страница сообществ - Skyline Community. К сожалению, пока службы VMware Skyline доступны для пользователей Premier Services в Северной Америке, Австралии, Индии, Новой Зеландии и Сингапуре, а для пользователей Production Support это возможно только в Северной Америке.

В ближайшем будущем эта география будет расширена: в середине 2018 года будут подключены пользователи Premier Services регионов EMEA и APJ/ANZ (в этих же регионах для Production Support приглашения будут в конце 2018 - начале 2019), а также все пользователи Северной и Южной Америки.

На сайте проекта VMware Labs появилось второе (со времени выхода VMware vSphere 6.7) обновление HTML5-клиента для управления виртуальной инфраструктурой - VMware vSphere Client 3.39. Напомним, что о прошлых версиях этого тонкого клиента мы писали около месяца назад вот тут.

Давайте посмотрим, что нового появилось в VMware vSphere Client 3.39:

• Полностью реализованная функциональность механизма автоматизированного развертывания хостов Auto Deploy (то же самое, что есть сейчас в vSphere Web Client):
• Software Depots
• Deploy Rules
• Deployed Hosts
• Discovered Hosts
• Configure (настройка самого Auto-Deploy)
• Поддержка бандлов скриптов для Auto-Deploy (теперь это есть только в vSphere Client):
• Просмотр бандлов скриптов в списке всех бандлов
• Возможность загрузить бандл скриптов
• Возможность добавить или изменить правила развертывания с бандлами скриптов
• Новое представление виртуальных коммутаторов на хосте, которое включает в себя диаграммы с топологиями для стандартных виртуальных коммутаторов, а также host proxy switches.
• Улучшенная функциональность для виртуальных сервисов vApp и виртуальных машин в их составе: создание, редактирование, удаление, изменение значений.
• Были улучшены vCenter Extensions.
• Доработаны правила механизма Storage DRS для виртуальных машин - создание, редактирование и удаление.

Скачать VMware vSphere Client 3.39 можно по этой ссылке.

Вчера мы писали о том, что компания VMware выпустила документ, посвященный производительности последней версии платформы -  What’s New in Performance - VMware vSphere 6.7. Между тем, на днях также стал доступен и документ, рассказывающий обо всех новых возможностях продукта - What's New in vSphere 6.7.

В целом, обо всем этом мы писали в различных статьях про VMware vSphere 6.7, которые собраны здесь, но почитать whitepaper все равно будет не лишним, так как там есть несколько интересных деталей. Например, хорошая визуализация позиционирования памяти Persistent Memory:

Основные разделы документа:

• vCenter Server 6.7
• vSphere 6.7 Lifecycle Management
• vSphere with Operations Management 6.7
• vSphere 6.7 Developer and Automation Interfaces
• vSphere 6.7 Security
• vSphere 6.7 for Enterprise Applications
• Remote Directory Memory Access

Скачать док What's New in vSphere 6.7 можно по этой ссылке. Также вам может оказаться страница со всеми техническими ресурсами о новой версии платформы - vSphere 6.7 Technical Assets.

Компания VMware на днях выпустила новый документ, раскрывающий основные моменты улучшения производительности VMware vSphere 6.7 по сравнению с прошлой версией - What’s New in Performance - VMware vSphere 6.7.

В документе рассматриваются несколько основных улучшений, которые были сделаны в платформе:

• Увеличение в 2 раза числа операций vCenter в секунду по сравнению с vCenter 6.5.
• vCenter использует в 3 раза меньше памяти для основного процесса vpxd.
• Уменьшение времени на операции, связанных с DRS, до 3 раз (например, запуск виртуальной машины).
• Улучшение производительности Virtualization Based Security.

Здесь повышение производительности в числе транзакций в минуту составило 33% по сравнению с работой VBS в vSphere 6.5:

• Поддержка больших страниц памяти (Large Memory Pages) размером 1 ГБ.

Хост ESXi с размером страницы в 1 ГБ (появилось в vSphere 6.7) работает на 26% лучше, чем хост со страницей в 2 МБ:

• Улучшения драйвера vmxnet3 версии 4 в плане механизмов RSS (улучшение 28-146% в числе полученных пакетов в секунду) и VXLAN/Geneve Offload (до 415% улучшение в пропускной способности канала при некоторых условиях).
• Поддержка новых сервисов Persistent Memory.

С помощью технологии vSphere Persistent Memory пользователи могут применять специальные аппаратные модули от Dell-EMC и HPE (DRAM NVDIMM), которые могут использовать высокопроизводительные системы хранения с большим числом IOPS или предоставлять их возможности гостевым системам как non-volatile memory.

Работает это быстрее, чем SSD (vPMEMDisk - это работа такой памяти как локальное хранилище хоста ESXi, а vPMEM - прямое предоставление хранилища гостевой системе как устройства):

• Скорость создания мгновенных клонов (Instant Clones) виртуальных машин по сравнению со скоростью создания связанных клонов.

Мгновенные клоны создаются почти в три раза быстрее, чем связанные (время в секундах на создание 64 клонов):

Все остальное - в документе "What’s New in Performance - VMware vSphere 6.7".

7 лет назад мы писали про утилиту ESXi-Customizer, которая позволяет добавлять кастомные драйвера в ISO-образ VMware ESXi. У того же автора (Andreas Peetz) есть еще одна замечательная утилита, которая актуальна и на сегодняшний день - ESXi-Customizer-PS. Актуальна - это значит, что ее последняя версия (от 18 апреля этого года) поддерживает последние версии платформ и фреймворка - vSphere 6.7 и PowerCLI 10.

ESXi-Customizer-PS - это PowerShell-скрипт, который на входе принимает большое число различных параметров, а на выходе дает кастомизированный ISO-образ или офлайн-бандл ESXi:

Сценарий имеет три режима работы:

• Создать установочный образ ISO или Offline Bundle напрямую из хранилища VMware Online depot (стандартный режим).
• Создать установочный образ ISO или Offline Bundle из скачанного ESXi Offline Bundle (параметр -izip).
• Обновление локального ESXi Offline Bundle с помощью ESXi patch bundle из хранилища VMware Online depot (параметры -izip -update).

С помощью этих трех режимов вы можете добавлять бандлы из хранилища V-Front Online Depot, либо любого другого Online Depot, указав его URL, а также можно указывать локальные Offline Bundles и VIB-файлы (собственно, кастомные драйверы или кастомный софт под ESXi).

Об использовании утилиты ESXi-Customizer-PS Alex Lopez снял хороший видеотуториал:

Скрипт можно использовать множеством способов. Давайте рассмотрим основные:

1. Вызов скрипта без параметров.

Например:

.\ESXi-Customizer-PS-v2.6.0.ps1

В этом случае утилита создаст ISO-образ ESXi самой последней версии (6.7 на данный момент) и с самым последним уровнем обновлений. Вы также можете указать конкретный номер версии ESXi, для которой будет получен ISO с последними обновлениями. Например:

• -v50 : ESXi 5.0 ISO
• -v51 : ESXi 5.1 ISO
• -v55 : ESXi 5.5 ISO
• -v60 : ESXi 6.0 ISO
• -v65 : ESXi 6.5 ISO
• -v67 : ESXi 6.7 ISO

Также есть еще три параметра:

• -outDir : записывать ISO-образ в указанную директорию.
• -sip : не использует последний уровень патчей, а показывает меню, где можно выбрать конкретный патч. Новые патчи будут показаны сверху. Также будут показаны и профили, которые содержат только обновления безопасности и/или VMware Tools.
• -ozip : на выходе будет сформирован не ISO, а ESXi Offline Bundle, который можно импортировать в Update Manager, указать вручную для обновления черезesxcli или использовать как входной бандл для следующих кастомизаций.

2. Использование офлайн бандла ESXi Offline Bundle как входного параметра (вместо VMware Online depot).

Например, такая команда позволит вам получить ISO-образ из офлайн-бандла:

.\ESXi-Customizer-PS-v2.6.0.ps1 -izip .\VMware-ESXi-6.0.0-2494585-depot.zip

Офлайн бандл можно скачать через VMware Patch Download portal. Некоторые вендоры также предлагают свои кастомизированные офлайн-бандлы, например HP. Офлайн бандлы VMware можно найти вот тут. Также вы можете использовать параметры из пункта 1.

3. Добавление дополнительных пакетов из присоединенных хранилищ Online depots.

Например, вот эта команда позволит добавить сетевые драйверы, отсутствующие в образе ESXi 5.5:

.\ESXi-Customizer-PS-v2.6.0.ps1 -v55 -load net-r8168,net-r8169,net-sky2

Данные драйверы есть в VMware Online depot, так как они есть в составе ESXi 5.0 и 5.1, но были исключены из дистрибутива ESXi 5.5. Важно, что для ESXi 6.0 такая штука для этих драйверов уже не прокатит, так как они были добавлены в черный список (blacklised).

4. Присоединение онлайн-хранилища V-Front Online Depot и других хранилищ.

Делается это следующей командой:

.\ESXi-Customizer-PS-v2.6.0.ps1 -v60 -vft -load sata-xahci,net55-r8168

В результате в образ ESXi 6.0 будут добавлены драйверы из V-Front Online Depot (sata-xahci и net55-r8168).

5. Добавление локальных офлайн-бандлов и VIB-файлов.

Вот такая команда добавит все офлайн-бандлы и VIB-пакеты в последний образ ESXi 6.7:

.\ESXi-Customizer-PS-v2.6.0.ps1 -pkgDir C:\temp\pkg

Этой командой вы сможете добавить драйверы типа 3rd party или community supported.

6. Обновление локальных офлайн-бандлов.

Вот такая команда обновит ESXi 6.0 Offline bundle последними патчами из онлайн-хранилища VMware:

.\ESXi-Customizer-PS-v2.6.0.ps1 -v60 -izip .\VMware-ESXi-6.0.0-2494585-HP-600.9.1.39-Mar2015-depot.zip -update

Здесь надо не забывать указывать номер версии патчируемого гипервизора (в данном случае -v60 - это ESXi 6.0).

7. Расширенные параметры.

У утилиты есть еще несколько расширенных параметров, которые дают еще больше возможностей по кастомизации образов ESXi:

• -log : указание пути к кастомному лог-файлу.
• -test : тестирование возможности построения или обновления образа без накатывания реальных изменений. Экономит массу времени, так как не перестраивает ISO или zip, а также не качает обновления и образы из VMware Online depot.
• -nsc : это опция -noSignatureCheck, которая отключает проверку сигнатуры при выполнении функции экспорта. Ее нужно использовать, если вы получаете ошибку типа "Could not find trusted signer." (пакет с некорректными или отсутствующими сигнатурами).
• -ipname, -ipdesc, -ipvendor: задание собственных атрибутов в профиле образа. По умолчанию в имени и описании останутся прежние значения с приставкой "customized", а имя вендора не изменится.
• -remove vib1[,...]: удаление одного или нескольких VIB-пакетов из кастомного образа.

Скачать ESXi-Customizer-PS-v2.6.0.ps1 можно по этой ссылке.